主路徑的頁都在了。接下來最容易讓整座大廳失信的，不是缺功能，而是 同一件事在不同頁用不同的話說。 通過有時是綠勾、有時是 OK、有時是沒有紅字；沒資料有時是空白、有時是零、有時是轉圈圈。PM 與工程師會重新開始各看各的。這堂課把全站的語意收斂：燈號、缺值、空狀態、以及燈號不對時怎麼從畫面走回 JSON。

這不是美術課。顏色可以改，詞彙不能散。詞彙一散，Day 14 許下的「同一份現況」就只剩同一份網址。

一、燈號只有四態，規則只有一句

四態：通過、失敗、警告、未知。規則只有一句，全站共用：

  有失敗？ ──是──► 失敗（紅）
     │否
     ▼
  有警告？ ──是──► 警告（黃）
     │否
     ▼
  該過的都過了？ ──是──► 通過（綠）
     │否
     ▼
  未知          有檢查結構但推不出判決
  橫線「—」     連結構都沒有（還沒跑）← 不是灰燈

專案表、檢查表標題、檢查列、Summary 的狀態欄，全部用這一句。不要為了某一頁好看把失敗畫成橘、把警告畫成灰。

未知與「沒有資料」不同。未知是有檢查結構、但計數推不出判決。沒有資料是連結構都沒有，應走空狀態，不是畫一顆灰燈假裝審過。灰燈在會議上會被當成「有跑但不確定」，空文案會被當成「還沒跑」。兩種行動完全不同：一個要去翻檢查項，一個要去催上傳。

顏色綁在 class 上，文字綁在狀態字上。PASS／FAIL／WARN 來自資料，不要在畫面把 FAIL 顯示成「需注意」這類較軟的詞。軟詞會讓人以為還有討論空間。真要討論，那是 Waive 的題，不是改燈號文案能解決的。

數字的顯示也要全站同一套：空就是「—」，整數就是整數，小數固定到可比較的位數。不要同一份 DRC 在葉子表是 12、在並排表是 12.000、在 Summary 是 12.0。對帳的人會以為那是三次 run。格式化是顯示層的契約，與箱子裡存什麼整數無關。

二、三種「沒有」必須能分開說

第一種：產品還沒做。PV、STA、IR 的灰色頁籤與占位卡。文案是尚未啟用、稍後才來。這不是使用者的錯。

第二種：產品做了，這顆還沒有這類資料。APR 門沒有上傳、SignOff 沒有 stage_qa、Summary 某列還沒跑。文案要指出缺的是哪一種檔、哪一個階段。最好順便提起父親空白即為根這類契約，讓丟檔的人能自修。

第三種：有資料，但這一格沒有這個鍵。並排表的「—」屬於這種。意思是這一站當時沒抽這個指標，不是這一站是零，也不是網站壞了。

三種共用一句「沒有資料」，現場會修錯地方。第一種去催開發，第二種去催流程，第三種去改 dict。畫面有責任把人送到正確的那條催促。

載入中是第四種，而且是暫時的。它應該是主畫面的一種正式狀態，不是某一張表自己轉圈。失敗同樣正式：讀檔失敗、清單失敗，錯誤字寫在主畫面。永遠轉圈而不失敗，比失敗更糟，因為沒有人知道該停下來查哪一層。

三、對帳手勢：從眼睛看到的格子往外走

格子裡的 12 被質疑時，順序固定，不要跳：

  眼睛看到的格子 12
        │
        ▼
  我在哪一頁、哪扇門、哪個版本？（Summary 的最新 ≠ Version 上某一站）
        │
        ▼
  打開對應 JSON，搜同一個鍵
        ├── 12 在     → 畫面取值路徑錯了
        └── 12 不在   → 箱子或 TCL 翻譯錯了，回頭對報告

不要先改 CSS，也不要先改燈號規則「讓它看起來比較對」。

路徑類欄位不應出現在對帳路徑上。若網頁上看到工作目錄，那是正規化沒清乾淨，先當缺陷修掉，免得會議變成「這個路徑是哪台機器」。對帳只認指標鍵與檢查名。

同一個 block 在 Project 表、Block 標題列、Summary 列上的日期與燈號，應能解釋成同一套「最新」定義。解釋不了，就是有人在某一頁用了另一種排序或另一個階段。Day 21 把兩種最新講死，這裡要的是執行：抽查三顆 block，三頁對一次。

四、文字要像給現場的人看，不是給框架看

空狀態裡的 dist/design/、stage_qa、father 可以保留——丟檔的人需要這些詞才能自修。但不要只丟識別名。先說人話，再括契約裡的鍵。例如：這個 block 還沒有 SignOff 檢查；需要上傳裡帶 stage_qa。順序是讀者、然後才是欄位。

錯誤訊息同樣。Failed to load 某個網址，應讓人看出是清單還是某一份 JSON。檔名要在。編碼後的網址很難讀，能顯示原始檔名更好。現場會把錯誤拍成照片丟進群組，照片裡看得到檔名，才有人幫得上。

頂部路徑與副標也是語意。它們不是裝飾。副標說你在哪一層，頂部路徑說怎麼回去。兩者與燈號無關，但與「我是不是走丟了」有關。走丟的人不會相信燈號。

五、什麼時候不該讓畫面更聰明

不要自動把橫線畫成通過，即使這顆 block 從未被要求 SignOff。政策上「不適用」應是檢查項裡的一種狀態，由箱子說，不由畫面猜。

不要因為 DRC 是 0 就在 APR 表加一顆綠燈。DRC 零不是 SignOff 通過。綠只留給檢查判決。

不要在空表放示範列。示範會被當成真資料截圖進週報。

不要為了「比較不會嚇到主管」把 FAIL 改成 WARN 顯示。驚嚇是資訊。Waive 若發生，應留下紀錄與另一種明確標記，而不是把燈變暗。那是 Day 24 的接縫，今天先禁止默默改判。

六、用一張核對表當全站契約

抽一顆有 APR、有 SignOff、樹上還有一顆完全沒跑的 block。確認：

• 沒跑的那顆：Project 燈號橫線、葉子零；Summary 寫還沒跑；點進去 APR 門是空說明，不是灰燈。
• 有跑的那顆：Project 葉數量等於 Block 門葉子列數；Summary APR 版本等於最新葉子版本；Summary 燈號等於檢查門總燈號等於 Project 燈號。
• Version 並排表裡缺的鍵是「—」，不是 0；DRC 的 12 與 JSON 裡同一個鍵相同。
• 刷新、無痕貼上網址，上述全同。

全部成立，語意才算收斂。差一項，先改規則或取值，不要加新顏色。

七、會議上最常發生的四種誤讀

第一種：把橫線當成通過。修法是圖例，不是改規則。在專案表或 Summary 角落用四個字說明：綠過、紅敗、黃警、橫線還沒跑。只寫一次，全站共用。

第二種：把 DRC 零當成 SignOff 通過。修法是不給 APR 表燈號。有人要求加，回這篇。綠只來自檢查判決。

第三種：Summary 的最新與工程師正在 Version 裡看的那一站不同。這不是 bug。講清楚「最新切片」與「譜系上某一站」。若會議要鎖定某一站，傳 Version 網址，不要傳 Summary 網址。

第四種：同一顆 block 在 Project 與 SignOff 門燈號不同。這才是 bug，或是刷新前後磁碟變了。先刷新兩頁，仍不同再查是否某一頁用了別的「最新」定義。

路徑被畫出來也是誤讀的來源。格子裡出現 /proj/.../rpt 時，對帳會變成討論機器。正規化應在進畫面前記住：鍵名或值長得像路徑就丟掉。漏網的當缺陷，不當特色。

字體上，狀態用短詞、識別用等寬、說明用淡色。三層分得開，投影才掃得完。不要讓 FAIL 與 block 名一樣粗、一樣色，否則紅燈會被名字吃掉。